home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++,comp.lang.c,comp.std.c
- Path: blackbush.xlink.net!slsv6bt!slsv6bt!kanze
- From: kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763)
- Subject: Re: Hungarian notation
- In-Reply-To: seebs@solutions.solon.com's message of 27 Jan 1996 03:18:15 -0600
- Message-ID: <KANZE.96Jan29124454@slsvewt.lts.sel.alcatel.de>
- Sender: news@lts.sel.alcatel.de
- Organization: SEL
- References: <30C40F77.53B5@swsbbs.com> <JSA.96Jan26175507@organon.com>
- <31098190.8106176@nntp.ix.netcom.com>
- <4eco1g$aih@fountain.mindlink.net> <4ecqkn$p1t@solutions.solon.com>
- Date: 29 Jan 1996 11:44:54 GMT
-
- In article <4ecqkn$p1t@solutions.solon.com> seebs@solutions.solon.com
- (Peter Seebach) writes:
-
- |> In article <4eco1g$aih@fountain.mindlink.net>,
- |> Gene Wirchenko <genew@mindlink.bc.ca> wrote:
- |> >>I claim that ISO 6.2.1.2 requires that an implementation actually do
- |> >>such a conversion. The implementor may choose the mapping. Beside
- |> >>the usual throwing away of high order bits, possibilities include
- |> >>always using the value 0, or the largest possible value for the new
- |> >>type, or, even, a random value.
-
- |> > Implementation defined means implementation defined, not what you
- |> >want it to mean. I agree that your interpretation sets out reasonable
- |> >actions that might be performed. Please quote chapter and verse on
- |> >where the Standard states that implementation defined actions must be
- |> >"reasonable" (whatever the hell that is <G>).
-
- |> Ahh, but there is the key.
-
- |> My understanding (and I believe this is Mike's point) is that there is
- |> a different between implementation defined *BEHAVIOR* and an implementation
- |> defined *RESULT*.
-
- |> My understanding is that integer conversions are an implementation
- |> defined *RESULT*. No other *behavior* is allowed - the semantics do
- |> not imply or show any.
-
- [...]
- |> However, given something where the *result* is implementation defined, I
- |> would expect that no unexpected *behavior* was allowed.
-
- Well, I suppose I would argue that getting a signal in such a case
- would be the expected behavior, so there is still no unexpected
- behavior:-).
-
- In fact, given the difference in wording between this and
- floating-point conversions, I fear that the committee did intend to
- ban reasonable behavior in this case.
-
- [...]
- |> > What if the conversion results in overflow?
-
- |> This is actually a legitimate question; if conversion is taken to be
- |> an operation, then the previously pointed out limit on all arithmetic
- |> ops comes into play, and we have full-fleged *undefined behavior* -
- |> easily enough to format a disk with.
-
- This would almost seem to forbid the check in an implicit conversion,
- but allow it in an explicit one (cast *operator*):-).
- --
- James Kanze Tel.: (+33) 88 14 49 00 email: kanze@gabi-soft.fr
- GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
- Conseils, Θtudes et rΘalisations en logiciel orientΘ objet --
- -- A la recherche d'une activitΘ dans une region francophone
-
-